home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 7 / Apprentice-Release7.iso / Environments / PowerLisp 2.01 / Supplemental Documentation / Documentation / Chapter 09. Declarations < prev    next >
Text File  |  1995-03-27  |  51KB  |  1,152 lines
  1. Common Lisp the Language, 2nd Edition
  2. -------------------------------------------------------------------------------
  3.  
  4. 9. Declarations
  5.  
  6. Declarations allow you to specify extra information about your program to the
  7. Lisp system. With one exception, declarations are completely optional and
  8. correct declarations do not affect the meaning of a correct program. The
  9. exception is that special declarations do affect the interpretation of variable
  10. bindings and references and so must be specified where appropriate. All other
  11. declarations are of an advisory nature, and may be used by the Lisp system to
  12. aid the programmer by performing extra error checking or producing more
  13. efficient compiled code. Declarations are also a good way to add documentation
  14. to a program.
  15.  
  16. Note that it is considered an error for a program to violate a declaration
  17. (such as a type declaration), but an implementation is not required to detect
  18. such errors (though such detection, where feasible, is to be encouraged).
  19.  
  20. -------------------------------------------------------------------------------
  21.  
  22.    *  Declaration Syntax
  23.    *  Declaration Specifiers
  24.    *  Type Declaration for Forms
  25.  
  26. -------------------------------------------------------------------------------
  27.  
  28. 9.1. Declaration Syntax
  29.  
  30. The declare construct is used for embedding declarations within executable
  31. code. Global declarations and declarations that are computed by a program are
  32. established by the proclaim construct.
  33.  
  34. [change_begin]
  35. X3J13 voted in June 1989 (PROCLAIM-ETC-IN-COMPILE-FILE)   to introduce the new
  36. macro declaim, which is guaranteed to be recognized appropriately by the
  37. compiler and is often more convenient than proclaim for establishing global
  38. declarations.
  39. [change_end]
  40.  
  41. [Special Form]
  42. declare {decl-spec}*
  43.  
  44. A declare form is known as a declaration. Declarations may occur only at the
  45. beginning of the bodies of certain special forms; that is, a declaration may
  46. occur only as a statement of such a special form, and all statements preceding
  47. it (if any) must also be declare forms (or possibly documentation strings, in
  48. some cases). Declarations may occur in lambda-expressions and in the forms
  49. listed here.
  50.  
  51. define-setf-method              labels
  52. defmacro                        let
  53. defsetf                         let*
  54. deftype                         locally
  55. defun                           macrolet
  56. do                              multiple-value-bind
  57. do*                             prog
  58. do-all-symbols                  prog*
  59. do-external-symbols             with-input-from-string
  60. do-symbols                      with-open-file
  61. dolist                          with-open-stream
  62. dotimes                         with-output-to-string
  63. flet
  64.  
  65. [change_begin]
  66. Notice of correction. In the first edition, the above list failed to mention
  67. the forms define-setf-method, with-input-from-string, with-open-file,
  68. with-open-stream, and with-output-to-string, even though their individual
  69. descriptions in the first edition specified that declarations may appear in
  70. those forms.
  71. [change_end]
  72.  
  73. X3J13 voted in June 1989 (CONDITION-RESTARTS)   to add with-condition-restarts
  74. and also (DATA-IO)   to add print-unreadable-object and
  75. with-standard-io-syntax. The X3J13 vote left it unclear whether these macros
  76. permit declarations to appear at the heads of their bodies. I believe that was
  77. the intent, but this is only my interpretation.
  78.  
  79. [change_begin]
  80. X3J13 voted in June 1988 (CLOS)   to adopt the Common Lisp Object System, which
  81. includes the following additional forms in which declarations may occur:
  82.  
  83. defgeneric                      generic-function
  84. define-method-combination       generic-labels
  85. defmethod                       with-added-methods
  86. generic-flet
  87.  
  88. Furthermore X3J13 voted in January 1989 (SYMBOL-MACROLET-DECLARE)   to allow
  89. declarations to occur before the bodies of these forms:
  90.  
  91. symbol-macrolet                 with-slots
  92. with-accessors
  93.  
  94. There are certain aspects peculiar to symbol-macrolet (and therefore also to
  95. with-accessors and with-slots, which expand into uses of symbol-macrolet). An
  96. error is signaled if a name defined by symbol-macrolet is declared special, and
  97. a type declaration of a name defined by symbol-macrolet is equivalent in effect
  98. to wrapping a the form mentioning that type around the expansion of the defined
  99. symbol.
  100. [change_end]
  101.  
  102. It is an error to attempt to evaluate a declaration. Those special forms that
  103. permit declarations to appear perform explicit checks for their presence.
  104.  
  105. -------------------------------------------------------------------------------
  106. Compatibility note: In MacLisp, declare is a special form that does nothing but
  107. return the symbol declare as its result. The MacLisp interpreter knows nothing
  108. about declarations but just blindly evaluates them, effectively ignoring them.
  109. The MacLisp compiler recognizes declarations but processes them simply by
  110. evaluating the subforms of the declaration in the compilation context. In
  111. Common Lisp it is important that both the interpreter and compiler recognize
  112. declarations (especially special declarations) and treat them consistently, and
  113. so the rules about the structure and use of declarations have been made
  114. considerably more stringent. The odd tricks played in MacLisp by writing
  115. arbitrary forms to be evaluated within a declare form are better done in both
  116. MacLisp and Common Lisp by using eval-when.
  117. -------------------------------------------------------------------------------
  118.  
  119. It is permissible for a macro call to expand into a declaration and be
  120. recognized as such, provided that the macro call appears where a declaration
  121. may legitimately appear. (However, a macro call may not appear in place of a
  122. decl-spec.)
  123.  
  124. [change_begin]
  125. X3J13 voted in March 1988 (DECLARE-MACROS)   to eliminate the recognition of a
  126. declaration resulting from the expansion of a macro call. This feature proved
  127. to be seldom used and awkward to implement in interpreters, compilers, and
  128. other code-analyzing programs.
  129.  
  130. Under this change, a declaration is recognized only as such if it appears
  131. explicitly, as a list whose car is the symbol declare, in the body of a
  132. relevant special form. (Note, however, that it is still possible for a macro to
  133. expand into a call to the proclaim function.)
  134. [change_end]
  135.  
  136. Each decl-spec is a list whose car is a symbol specifying the kind of
  137. declaration to be made. Declarations may be divided into two classes: those
  138. that concern the bindings of variables, and those that do not. (The special
  139. declaration is the sole exception: it effectively falls into both classes, as
  140. explained below.) Those that concern variable bindings apply only to the
  141. bindings made by the form at the head of whose body they appear. For example,
  142. in
  143.  
  144. (defun foo (x)
  145.   (declare (type float x)) ...
  146.   (let ((x 'a)) ...)
  147.   ...)
  148.  
  149. the type declaration applies only to the outer binding of x, and not to the
  150. binding made in the let.
  151.  
  152. -------------------------------------------------------------------------------
  153. Compatibility note: This represents a difference from MacLisp, in which type
  154. declarations are pervasive.
  155. -------------------------------------------------------------------------------
  156.  
  157. Declarations that do not concern themselves with variable bindings are
  158. pervasive, affecting all code in the body of the special form. As an example of
  159. a pervasive declaration,
  160.  
  161. (defun foo (x y) (declare (notinline floor)) ...)
  162.  
  163. advises that everywhere within the body of foo the function floor should not be
  164. open-coded but called as an out-of-line subroutine.
  165.  
  166. Some special forms contain pieces of code that, properly speaking, are not part
  167. of the body of the special form. Examples of this are initialization forms that
  168. provide values for bound variables, and the result forms of iteration
  169. constructs. In all cases such additional code is within the scope of any
  170. pervasive declarations appearing before the body of the special form.
  171. Non-pervasive declarations have no effect on such code, except (of course) in
  172. those situations where the code is defined to be within the scope of the
  173. variables affected by such non-pervasive declarations. For example:
  174.  
  175. (defun few (x &optional (y *print-circle*))
  176.   (declare (special *print-circle*))
  177.   ...)
  178.  
  179. The reference to *print-circle* in the first line of this example is special
  180. because of the declaration in the second line.
  181.  
  182. (defun nonsense (k x z)
  183.   (foo z x)               ;First call to foo
  184.   (let ((j (foo k x))     ;Second call to foo
  185.         (x (* k k)))
  186.     (declare (inline foo) (special x z))
  187.     (foo x j z)))         ;Third call to foo
  188.  
  189. In this rather nonsensical example, the inline declaration applies to the
  190. second and third calls to foo, but not to the first one. The special
  191. declaration of x causes the let form to make a special binding for x and causes
  192. the reference to x in the body of the let to be a special reference. The
  193. reference to x in the second call to foo is also a special reference. The
  194. reference to x in the first call to foo is a local reference, not a special
  195. one. The special declaration of z causes the reference to z in the call to foo
  196. to be a special reference; it will not refer to the parameter to nonsense named
  197. z, because that parameter binding has not been declared to be special. (The
  198. special declaration of z does not appear in the body of the defun, but in an
  199. inner construct, and therefore does not affect the binding of the parameter.)
  200.  
  201. [change_begin]
  202. X3J13 voted in January 1989 (DECLARATION-SCOPE)   to replace the rules
  203. concerning the scope of declarations occurring at the head of a special form or
  204. lambda-expression:
  205.  
  206.    *  The scope of a declaration always includes the body forms, as well as any
  207.      ``stepper'' or ``result'' forms (which are logically part of the body), of
  208.      the special form or lambda-expression.
  209.  
  210.    *  If the declaration applies to a name binding, then the scope of the
  211.      declaration also includes the scope of the name binding.
  212.  
  213. Note that the distinction between pervasive and non-pervasive declarations is
  214. eliminated. An important change from the first edition is that
  215. ``initialization'' forms are specifically not included as part of the body
  216. under the first rule; on the other hand, in many cases initialization forms may
  217. fall within the scope of certain declarations under the second rule.
  218.  
  219. X3J13 also voted in January 1989 (DECLARE-TYPE-FREE)   to change the
  220. interpretation of type declarations (see section 9.2).
  221.  
  222. These changes affect the interpretation of some of the examples from the first
  223. edition.
  224.  
  225. (defun foo (x)
  226.   (declare (type float x)) ...
  227.   (let ((x 'a)) ...)
  228.   ...)
  229.  
  230. Under the interpretation approved by X3J13, the type declaration applies to
  231. both bindings of x. More accurately, the type declaration is considered to
  232. apply to variable references rather than bindings, and the type declaration
  233. refers to every reference in the body of foo to a variable named x, no matter
  234. to what binding it may refer.
  235.  
  236. (defun foo (x y) (declare (notinline floor)) ...)
  237.  
  238. This example of the use of notinline stands unchanged, but the following slight
  239. extension of it would change:
  240.  
  241. (defun foo (x &optional (y (floor x)))
  242.   (declare (notinline floor)) ...)
  243.  
  244. Under first edition rules, the notinline declaration would be considered to
  245. apply to the call to floor in the initialization form for y. Under the
  246. interpretation approved by X3J13, the notinline would not apply to that
  247. particular call to floor. Instead the user must write something like
  248.  
  249. (defun foo (x &optional (y (locally (declare (notinline floor))
  250.                                     (floor x))))
  251.   (declare (notinline floor)) ...)
  252.  
  253. or perhaps
  254.  
  255. (locally (declare (notinline floor))
  256.   (defun foo (x &optional (y (floor x))) ...))
  257.  
  258. Similarly, the special declaration in
  259.  
  260. (defun few (x &optional (y *print-circle*))
  261.   (declare (special *print-circle*))
  262.   ...)
  263.  
  264. is not considered to apply to the reference in the initialization form for y in
  265. few. As for the nonsense example,
  266.  
  267. (defun nonsense (k x z)
  268.   (foo z x)               ;First call to foo
  269.   (let ((j (foo k x))     ;Second call to foo
  270.         (x (* k k)))
  271.     (declare (inline foo) (special x z))
  272.     (foo x j z)))         ;Third call to foo
  273.  
  274. under the interpretation approved by X3J13, the inline declaration is no longer
  275. considered to apply to the second call to foo, because it is in an
  276. initialization form, which is no longer considered in the scope of the
  277. declaration. Similarly, the reference to x in that second call to foo is no
  278. longer taken to be a special reference, but a local reference to the second
  279. parameter of nonsense.
  280. [change_end]
  281.  
  282. [old_change_begin]
  283.  
  284. [Macro]
  285. locally {declaration}* {form}*
  286.  
  287. This macro may be used to make local pervasive declarations where desired. It
  288. does not bind any variables and therefore cannot be used meaningfully for
  289. declarations of variable bindings. (Note that the special declaration may be
  290. used with locally to pervasively affect references to, rather than bindings of,
  291. variables.) For example:
  292.  
  293. (locally (declare (inline floor) (notinline car cdr))
  294.          (declare (optimize space))
  295.   (floor (car x) (cdr y)))
  296.  
  297. [old_change_end]
  298.  
  299. [change_begin]
  300. X3J13 voted in January 1989 (RETURN-VALUES-UNSPECIFIED)   to specify that
  301. locally executes the forms as an implicit progn and returns the value(s) of the
  302. last form.
  303.  
  304. X3J13 voted in March 1989 (LOCALLY-TOP-LEVEL)   to make locally be a special
  305. form rather than a macro. It still has the same syntax.
  306.  
  307. [Special Form]
  308. locally {declaration}* {form}*
  309.  
  310. This change was made to accommodate the new compilation model for top-level
  311. forms in a file (see section 25.1). When a locally form appears at top level,
  312. the forms in its body are processed as top-level forms. This means that one
  313. may, for example, meaningfully use locally to wrap declarations around a defun
  314. or defmacro form:
  315.  
  316. (locally
  317.   (declare (optimize (safety 3) (space 3) (debug 3) (speed 1)))
  318.   (defun foo (x &optional (y (abs x)) (z (sqrt y)))
  319.     (bar x y z)))
  320.  
  321. Without assurance that this works one must write something cumbersome such as
  322.  
  323.  
  324. (defun foo (x &optional (y (locally
  325.                               (declare (optimize (safety 3)
  326.                                                  (space 3)
  327.                                                  (debug 3)
  328.                                                  (speed 1)))
  329.                               (abs x)))
  330.                          (z (locally
  331.                               (declare (optimize (safety 3)
  332.                                                  (space 3)
  333.                                                  (debug 3)
  334.                                                  (speed 1)))
  335.                               (sqrt y))))
  336.   (locally
  337.     (declare (optimize (safety 3) (space 3) (debug 3) (speed 1)))
  338.     (bar x y z)))
  339.  
  340. [change_end]
  341.  
  342. [Function]
  343. proclaim decl-spec
  344.  
  345. The function proclaim takes a decl-spec as its argument and puts it into effect
  346. globally. (Such a global declaration is called a proclamation.) Because
  347. proclaim is a function, its argument is always evaluated. This allows a program
  348. to compute a declaration and then put it into effect by calling proclaim.
  349.  
  350. Any variable names mentioned are assumed to refer to the dynamic values of the
  351. variable. For example, the proclamation
  352.  
  353. (proclaim '(type float tolerance))
  354.  
  355. once executed, specifies that the dynamic value of tolerance should always be a
  356. floating-point number. Similarly, any function-names mentioned are assumed to
  357. refer to the global function definition.
  358.  
  359. A proclamation constitutes a universal declaration, always in force unless
  360. locally shadowed. For example,
  361.  
  362. (proclaim '(inline floor))
  363.  
  364. advises that floor should normally be open-coded in-line by the compiler (but
  365. in the situation
  366.  
  367. (defun foo (x y) (declare (notinline floor)) ...)
  368.  
  369. it will be compiled out-of-line anyway in the body of foo, because of the
  370. shadowing local declaration to that effect).
  371.  
  372. [change_begin]
  373. X3J13 voted in January 1989 (SPECIAL-TYPE-SHADOWING)   to clarify that such
  374. shadowing does not occur in the case of type declarations. If there is a local
  375. type declaration for a special variable and there is also a global proclamation
  376. for that same variable, then the value of the variable within the scope of the
  377. local declaration must be a member of the intersection of the two declared
  378. types. This is consistent with the treatment of nested local type declarations
  379. on which X3J13 also voted in January 1989 (DECLARE-TYPE-FREE)   .
  380. [change_end]
  381.  
  382. As a special case (so to speak), proclaim treats a special decl-spec as
  383. applying to all bindings as well as to all references of the mentioned
  384. variables.
  385.  
  386. [change_begin]
  387. Notice of correction. In the first edition, this sentence referred to a
  388. ``special declaration-form.'' That was incorrect; proclaim accepts only a
  389. decl-spec, not a declaration-form.
  390. [change_end]
  391.  
  392. For example, after
  393.  
  394. (proclaim '(special x))
  395.  
  396. in a function definition such as
  397.  
  398. (defun example (x) ...)
  399.  
  400. the parameter x will be bound as a special (dynamic) variable rather than as a
  401. lexical (static) variable. This facility should be used with caution. The usual
  402. way to define a globally special variable is with defvar or defparameter.
  403.  
  404. [change_begin]
  405. X3J13 voted in June 1989 (PROCLAIM-ETC-IN-COMPILE-FILE)   to clarify that the
  406. compiler is not required to treat calls to proclaim any differently from the
  407. way it treats any other function call. If a top-level call to proclaim is to
  408. take effect at compile time, it should be surrounded by an appropriate
  409. eval-when form. Better yet, the new macro declaim may be used instead.
  410.  
  411. [Macro]
  412. declaim {decl-spec}*
  413.  
  414. This macro is syntactically like declare and semantically like proclaim. It is
  415. an executable form and may be used anywhere proclaim may be called. However,
  416. each decl-spec is not evaluated.
  417.  
  418. If a call to this macro appears at top level in a file being processed by the
  419. file compiler, the proclamations are also made at compile time. As with other
  420. defining macros, it is unspecified whether or not the compile-time side effects
  421. of a declaim persist after the file has been compiled (see section 25.1).
  422. [change_end]
  423.  
  424. -------------------------------------------------------------------------------
  425.  
  426. 9.2. Declaration Specifiers
  427.  
  428. Here is a list of valid declaration specifiers for use in declare. A construct
  429. is said to be ``affected'' by a declaration if it occurs within the scope of a
  430. declaration.
  431.  
  432. special
  433.      (special var1 var2 ...) specifies that all of the variables named are to
  434.      be considered special. This specifier affects variable bindings but also
  435.      pervasively affects references. All variable bindings affected are made to
  436.      be dynamic bindings, and affected variable references refer to the current
  437.      dynamic binding rather than to the current local binding. For example:
  438.  
  439.      (defun hack (thing *mod*)       ;The binding of the parameter
  440.        (declare (special *mod*))     ; *mod* is visible to hack1,
  441.        (hack1 (car thing)))          ; but not that of thing
  442.  
  443.      (defun hack1 (arg)
  444.        (declare (special *mod*))     ;Declare references to *mod*
  445.                                      ; within hack1 to be special
  446.        (if (atom arg) *mod*
  447.            (cons (hack1 (car arg)) (hack1 (cdr arg)))))
  448.  
  449.      Note that it is conventional, though not required, to give special
  450.      variables names that begin and end with an asterisk.
  451.  
  452.      A special declaration does not affect bindings pervasively. Inner bindings
  453.      of a variable implicitly shadow a special declaration and must be
  454.      explicitly re-declared to be special. (However, a special proclamation
  455.      does pervasively affect bindings; this exception is made for reasons of
  456.      convenience and compatibility with MacLisp.) For example:
  457.  
  458.      (proclaim '(special x))     ;x is always special
  459.  
  460.      (defun example (x y)
  461.        (declare (special y))
  462.        (let ((y 3) (x (* x 2)))
  463.          (print (+ y (locally (declare (special y)) y)))
  464.          (let ((y 4)) (declare (special y)) (foo x))))
  465.  
  466.      In the contorted code above, the outermost and innermost bindings of y are
  467.      special and therefore dynamically scoped, but the middle binding is
  468.      lexically scoped. The two arguments to + are different, one being the
  469.      value, which is 3, of the lexically bound variable y, and the other being
  470.      the value of the special variable named y (a binding of which happens,
  471.      coincidentally, to lexically surround it at an outer level). All the
  472.      bindings of x and references to x are special, however, because of the
  473.      proclamation that x is always special.
  474.  
  475.      As a matter of style, use of special proclamations should be avoided. The
  476.      defvar and defparameter macros are the conventional means for proclaiming
  477.      special variables in a program.
  478.  
  479. type
  480.      (type type var1 var2 ...) affects only variable bindings and specifies
  481.      that the variables mentioned will take on values only of the specified
  482.      type. In particular, values assigned to the variables by setq, as well as
  483.      the initial values of the variables, must be of the specified type.
  484.  
  485. [change_begin]
  486.  
  487.      X3J13 voted in January 1989 (DECLARE-TYPE-FREE)   to alter the
  488.      interpretation of type declarations. They are not to be construed to
  489.      affect ``only variable bindings.'' The new rule for a declaration of a
  490.      variable to have a specified type is threefold:
  491.  
  492.         o  It is an error if, during the execution of any reference to that
  493.           variable within the scope of the declaration, the value of the
  494.           variable is not of the declared type.
  495.  
  496.         o  It is an error if, during the execution of a setq of that variable
  497.           within the scope of the declaration, the new value for the variable
  498.           is not of the declared type.
  499.  
  500.         o  It is an error if, at any moment that execution enters the scope of
  501.           the declaration, the value of the variable is not of the declared
  502.           type.
  503.  
  504.      One may think of a type declaration (declare (type face bodoni)) as
  505.      implicitly changing every reference to bodoni within the scope of the
  506.      declaration to (the face bodoni); changing every expression exp assigned
  507.      to bodoni within the scope of the declaration to (the face exp); and
  508.      implicitly executing (the face bodoni) every time execution enters the
  509.      scope of the declaration.
  510.  
  511.      These new rules make type declarations much more useful. Under first
  512.      edition rules, a type declaration was useless if not associated with a
  513.      variable binding; declarations such as in
  514.  
  515.      (locally
  516.        (declare (type (byte 8) x y))
  517.        (+ x y))
  518.  
  519.      at best had no effect and at worst were erroneous, depending on one's
  520.      interpretation of the first edition. Under the interpretation approved by
  521.      X3J13, such declarations have ``the obvious natural interpretation.''
  522.  
  523.      X3J13 noted that if nested type declarations refer to the same variable,
  524.      then all of them have effect; the value of the variable must be a member
  525.      of the intersection of the declared types.
  526.  
  527.      Nested type declarations could occur as a result of either macro expansion
  528.      or carefully crafted code. There are three cases. First, the inner type
  529.      might be a subtype of the outer one:
  530.  
  531.      (defun compare (apples oranges)
  532.        (declare (type number apples oranges))
  533.        (cond ((typep apples 'fixnum)
  534.               ;; The programmer happens to know that, thanks to
  535.               ;; constraints imposed by the caller, if APPLES
  536.               ;; is a fixnum, then ORANGES will be also, and
  537.               ;; therefore wishes to avoid the unnecessary cost
  538.               ;; of checking ORANGES.  Nevertheless the compiler
  539.               ;; should be informed to allow it to optimize code.
  540.               (locally (declare (type fixnum apples oranges)))
  541.                        ;; Maybe the compiler could have figured
  542.                        ;; out by flow analysis that APPLES must
  543.                        ;; be a fixnum here, but it doesn't hurt
  544.                        ;; to say it explicitly.
  545.                 (< apples oranges)))
  546.              ((or (complex apples)
  547.                   (complex oranges))
  548.               (error "Not yet implemented.  Sorry."))
  549.              ...))
  550.  
  551.      This is the case most likely to arise in code written completely by hand.
  552.  
  553.      Second, the outer type might be a subtype of the inner one. In this case
  554.      the inner declaration has no additional practical effect, but it is
  555.      harmless. This is likely to occur if code declares a variable to be of a
  556.      very specific type and then passes it to a macro that then declares it to
  557.      be of a less specific type.
  558.  
  559.      Third, the inner and outer declarations might be for types that overlap,
  560.      neither being a subtype of the other. This is likely to occur only as a
  561.      result of macro expansion. For example, user code might declare a variable
  562.      to be of type integer, and a macro might later declare it to be of type
  563.      (or fixnum package); in this case a compiler could intersect the two types
  564.      to determine that in this instance the variable may hold only fixnums.
  565.  
  566.      The reader should note that the following code fragment is, perhaps
  567.      astonishingly, not in error under the interpretation approved by X3J13:
  568.  
  569.      (let ((james .007)
  570.            (maxwell 86))
  571.        (flet ((spy-swap ()
  572.                 (rotatef james maxwell)))
  573.          (locally (declare (integer maxwell))
  574.            (spy-swap)
  575.            (view-movie "The Sound of Music")
  576.            (spy-swap)
  577.            maxwell)))
  578.       => 86  (after a couple of hours of Julie Andrews)
  579.  
  580.      The variable maxwell is declared to be an integer over the scope of the
  581.      type declaration, not over its extent. Indeed maxwell takes on the
  582.      non-integer value .007 while the Trapp family make their escape, but
  583.      because no reference to maxwell within the scope of the declaration ever
  584.      produces a non-integer value, the code is correct.
  585.  
  586.      Now the assignment to maxwell during the first call to spy-swap, and the
  587.      reference to maxwell during the second call, do involve non-integer
  588.      values, but they occur within the body of spy-swap, which is not in the
  589.      scope of the type declaration! One could put the declaration in a
  590.      different place so as to include spy-swap in the scope:
  591.  
  592.      (let ((james .007)
  593.            (maxwell 86))
  594.        (locally (declare (integer maxwell))
  595.          (flet ((spy-swap ()
  596.                   (rotatef james maxwell)))
  597.            (spy-swap)                                   ;Bug!
  598.            (view-movie "The Sound of Music")
  599.            (spy-swap)
  600.            maxwell)))
  601.  
  602.      and then the code is indeed in error.
  603.  
  604.      X3J13 also voted in January 1989 (FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS)
  605.      to alter the meaning of the function type specifier when used in type
  606.      declarations (see section 4.5).
  607.  
  608. [change_end]
  609.  
  610. type
  611.      (type var1 var2 ...) is an abbreviation for (type type var1 var2 ...),
  612.      provided that type is one of the symbols appearing in table 4-1.
  613.  
  614. [change_begin]
  615.  
  616.      Observe that this covers the particularly common case of declaring numeric
  617.      variables:
  618.  
  619.      (declare (single-float mass dx dy dz)
  620.               (double-float acceleration sum))
  621.  
  622.      In many implementations there is also some advantage to declaring
  623.      variables to have certain specialized vector types such as base-string.
  624.  
  625. [change_end]
  626.  
  627. ftype
  628.      (ftype type function-name-1 function-name-2 ...) specifies that the named
  629.      functions will be of the functional type type, an example of which
  630.      follows. For example:
  631.  
  632.      (declare (ftype (function (integer list) t) nth)
  633.               (ftype (function (number) float) sin cos))
  634.  
  635.      Note that rules of lexical scoping are observed; if one of the functions
  636.      mentioned has a lexically apparent local definition (as made by flet or
  637.      labels), then the declaration applies to that local definition and not to
  638.      the global function definition.
  639.  
  640. [change_begin]
  641.  
  642.      X3J13 voted in March 1989 (FUNCTION-NAME)   to extend ftype declaration
  643.      specifiers to accept any function-name (a symbol or a list whose car is
  644.      setf - see section 7.1). Thus one may write
  645.  
  646.      (declaim (ftype (function (list) t) (setf cadr)))
  647.  
  648.      to indicate the type of the setf expansion function for cadr.
  649.  
  650.      X3J13 voted in January 1989 (FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS)   to
  651.      alter the meaning of the function type specifier when used in ftype
  652.      declarations (see section 4.5).
  653.  
  654. [change_end]
  655.  
  656. [old_change_begin]
  657.  
  658. function
  659.      (function name arglist result-type1 result-type2 ...) is entirely
  660.      equivalent to
  661.  
  662.      (ftype (function arglist result-type1 result-type2 ...) name)
  663.  
  664.      but may be more convenient for some purposes. For example:
  665.  
  666.      (declare (function nth (integer list) t)
  667.               (function sin (number) float)
  668.               (function cos (number) float))
  669.  
  670.      The syntax mildly resembles that of defun: a function-name, then an
  671.      argument list, then a specification of results.
  672.  
  673.      Note that rules of lexical scoping are observed; if one of the functions
  674.      mentioned has a lexically apparent local definition (as made by flet or
  675.      labels), then the declaration applies to that local definition and not to
  676.      the global function definition.
  677.  
  678. [old_change_end]
  679.  
  680. [change_begin]
  681. X3J13 voted in January 1989 (DECLARE-FUNCTION-AMBIGUITY)   to remove this
  682. interpretation of the function declaration specifier from the language.
  683. Instead, a declaration specifier
  684.  
  685. (function var1 var2 ...)
  686.  
  687. is to be treated simply as an abbreviation for
  688.  
  689. (type function var1 var2 ...)
  690.  
  691. just as for all other symbols appearing in table 4-1.
  692.  
  693. X3J13 noted that although function appears in table 4-1, the first edition also
  694. discussed it explicitly, with a different meaning, without noting whether the
  695. differing interpretation was to replace or augment the interpretation regarding
  696. table 4-1. Unfortunately there is an ambiguous case: the declaration
  697.  
  698. (declare (function foo nil string))
  699.  
  700. can be construed to abbreviate either
  701.  
  702. (declare (ftype (function () string) foo))
  703.  
  704. or
  705.  
  706. (declare (type function foo nil string))
  707.  
  708. The latter could perhaps be rejected on semantic grounds: it would be an error
  709. to declare nil, a constant, to be of type function. In any case, X3J13
  710. determined that the ice was too thin here; the possibility of confusion is not
  711. worth the convenience of an abbreviation for ftype declarations. The change
  712. also makes the language more consistent.
  713. [change_end]
  714.  
  715. inline
  716.      (inline function1 function2 ...) specifies that it is desirable for the
  717.      compiler to open-code calls to the specified functions; that is, the code
  718.      for a specified function should be integrated into the calling routine,
  719.      appearing in-line in place of a procedure call. This may achieve extra
  720.      speed at the expense of debuggability (calls to functions compiled in-line
  721.      cannot be traced, for example). This declaration is pervasive. Remember
  722.      that a compiler is free to ignore this declaration.
  723.  
  724.      Note that rules of lexical scoping are observed; if one of the functions
  725.      mentioned has a lexically apparent local definition (as established by
  726.      flet or labels), then the declaration applies to that local definition and
  727.      not to the global function definition.
  728.  
  729. [change_begin]
  730.  
  731.      X3J13 voted in October 1988 (PROCLAIM-INLINE-WHERE)   to clarify that
  732.      during compilation the inline declaration specifier serves two distinct
  733.      purposes: it indicates not only that affected calls to the specified
  734.      functions should be expanded in-line, but also that affected definitions
  735.      of the specified functions must be recorded for possible use in performing
  736.      such expansions.
  737.  
  738.      Looking at it the other way, the compiler is not required to save function
  739.      definitions against the possibility of future expansions unless the
  740.      functions have already been proclaimed to be inline. If a function is
  741.      proclaimed (or declaimed) inline before some call to that function but the
  742.      current definition of that function was established before the
  743.      proclamation was processed, it is implementation-dependent whether that
  744.      call will be expanded in-line. (Of course, it is implementation-dependent
  745.      anyway, because a compiler is always free to ignore inline declaration
  746.      specifiers. However, the intent of the committee is clear: for best
  747.      results, the user is advised to put any inline proclamation of a function
  748.      before any definition of or call to that function.)
  749.  
  750.      Consider these examples:
  751.  
  752.      (defun huey (x) (+ x 100))         ;Compiler need not remember this
  753.      (declaim (inline huey dewey))
  754.      (defun dewey (y) (huey (sqrt y)))  ;Call to huey unlikely to be expanded
  755.      (defun louie (z) (dewey (/ z)))    ;Call to dewey likely to be expanded
  756.  
  757.      X3J13 voted in March 1989 (FUNCTION-NAME)   to extend inline declaration
  758.      specifiers to accept any function-name (a symbol or a list whose car is
  759.      setf - see section 7.1). Thus one may write (declare (inline (setf cadr)))
  760.      to indicate that the setf expansion function for cadr should be compiled
  761.      in-line.
  762.  
  763. [change_end]
  764.  
  765. notinline
  766.      (notinline function1 function2 ...) specifies that it is undesirable to
  767.      compile the specified functions in-line. This declaration is pervasive. A
  768.      compiler is not free to ignore this declaration.
  769.  
  770.      Note that rules of lexical scoping are observed; if one of the functions
  771.      mentioned has a lexically apparent local definition (as made by flet or
  772.      labels), then the declaration applies to that local definition and not to
  773.      the global function definition.
  774.  
  775. [change_begin]
  776.  
  777.      X3J13 voted in March 1989 (FUNCTION-NAME)   to extend notinline
  778.      declaration specifiers to accept any function-name (a symbol or a list
  779.      whose car is setf - see section 7.1). Thus one may write (declare
  780.      (notinline (setf cadr))) to indicate that the setf expansion function for
  781.      cadr should not be compiled in-line.
  782.  
  783.      X3J13 voted in January 1989 (ALLOW-LOCAL-INLINE)   to clarify that the
  784.      proper way to define a function gnards that is not inline by default, but
  785.      for which a local declaration (declare (inline gnards)) has half a chance
  786.      of actually compiling gnards in-line, is as follows:
  787.  
  788.      (declaim (inline gnards))
  789.  
  790.      (defun gnards ...)
  791.  
  792.      (declaim (notinline gnards))
  793.  
  794.      The point is that the first declamation informs the compiler that the
  795.      definition of gnards may be needed later for in-line expansion, and the
  796.      second declamation prevents any expansions unless and until it is
  797.      overridden.
  798.  
  799.      While an implementation is never required to perform in-line expansion,
  800.      many implementations that do support such expansion will not process
  801.      inline requests successfully unless definitions are written with these
  802.      proclamations in the manner shown above.
  803.  
  804. [change_end]
  805.  
  806. ignore
  807.      (ignore var1 var2 ... varn) affects only variable bindings and specifies
  808.      that the bindings of the specified variables are never used. It is
  809.      desirable for a compiler to issue a warning if a variable so declared is
  810.      ever referred to or is also declared special, or if a variable is lexical,
  811.      never referred to, and not declared to be ignored.
  812.  
  813. optimize
  814.      (optimize (quality1 value1) (quality2 value2)...) advises the compiler
  815.      that each quality should be given attention according to the specified
  816.      corresponding value. A quality is a symbol; standard qualities include
  817.      speed (of the object code), space (both code size and run-time space),
  818.      safety (run-time error checking), and compilation-speed (speed of the
  819.      compilation process).
  820.  
  821. [change_begin]
  822.  
  823.      X3J13 voted in October 1988 (OPTIMIZE-DEBUG-INFO)   to add the standard
  824.      quality debug (ease of debugging).
  825.  
  826. [change_end]
  827.  
  828.      Other qualities may be recognized by particular implementations. A value
  829.      should be a non-negative integer, normally in the range 0 to 3. The value
  830.      0 means that the quality is totally unimportant, and 3 that the quality is
  831.      extremely important; 1 and 2 are intermediate values, with 1 the
  832.      ``normal'' or ``usual'' value. One may abbreviate (quality 3) to simply
  833.      quality. This declaration is pervasive. For example:
  834.  
  835.      (defun often-used-subroutine (x y)
  836.        (declare (optimize (safety 2)))
  837.        (error-check x y)
  838.        (hairy-setup x)
  839.        (do ((i 0 (+ i 1))
  840.             (z x (cdr z)))
  841.            ((null z) i)
  842.          ;; This inner loop really needs to burn.
  843.          (declare (optimize speed))
  844.          (declare (fixnum i))
  845.          )))
  846.  
  847. declaration
  848.      (declaration name1 name2 ...) advises the compiler that each namej is a
  849.      valid but non-standard declaration name. The purpose of this is to tell
  850.      one compiler not to issue warnings for declarations meant for another
  851.      compiler or other program processor.
  852.  
  853. [old_change_begin]
  854.  
  855.      This kind of declaration may be used only as a proclamation. For example:
  856.  
  857.      (proclaim '(declaration author
  858.                              target-language
  859.                              target-machine))
  860.  
  861.      (proclaim '(target-language ada))
  862.  
  863.      (proclaim '(target-machine IBM-650))
  864.  
  865.      (defun strangep (x)
  866.        (declare (author "Harry Tweeker"))
  867.        (member x '(strange weird odd peculiar)))
  868.  
  869. [old_change_end]
  870.  
  871. [change_begin]
  872.  
  873.      X3J13 voted in June 1989 (PROCLAIM-ETC-IN-COMPILE-FILE)   to introduce the
  874.      new macro declaim, which is guaranteed to be recognized appropriately by
  875.      the compiler and is often more convenient than proclaim for establishing
  876.      global declarations.
  877.  
  878.      The declaration declaration specifier may be used with declaim as well as
  879.      proclaim. The preceding examples would be better written using declaim, to
  880.      ensure that the compiler will process them properly.
  881.  
  882.      (declaim (declaration author
  883.                            target-language
  884.                            target-machine))
  885.  
  886.      (declaim (target-language ada)
  887.               (target-machine IBM-650))
  888.  
  889.      (defun strangep (x)
  890.        (declare (author "Harry Tweeker"))
  891.        (member x '(strange weird odd peculiar)))
  892.  
  893. X3J13 voted in March 1989 (DYNAMIC-EXTENT)   to introduce a new declaration
  894. specifier dynamic-extent for variables, and voted in June 1989
  895. (DYNAMIC-EXTENT-FUNCTION)   to extend it to handle function-names as well.
  896.  
  897. dynamic-extent
  898.  
  899.      (dynamic-extent item1 item2 ... itemn) declares that certain variables or
  900.      function-names refer to data objects whose extents may be regarded as
  901.      dynamic; that is, the declaration may be construed as a guarantee on the
  902.      part of the programmer that the program will behave correctly even if the
  903.      data objects have only dynamic extent rather than the usual indefinite
  904.      extent.
  905.  
  906.      Each item may be either a variable name or (function f) where f is a
  907.      function-name (see section 7.1). (Of course, (function f) may be
  908.      abbreviated in the usual way as #'f.)
  909.  
  910.      It is permissible for an implementation simply to ignore this declaration.
  911.      In implementations that do not ignore it, the compiler (or interpreter) is
  912.      free to make whatever optimizations are appropriate given this
  913.      information; the most common optimization is to stack-allocate the initial
  914.      value of the object. The data types that can be optimized in this manner
  915.      may vary from implementation to implementation.
  916.  
  917.      The meaning of this declaration can be stated more precisely. We say that
  918.      object x is an otherwise inaccessible part of y if and only if making y
  919.      inaccessible would make x inaccessible. (Note that every object is an
  920.      otherwise inaccessible part of itself.) Now suppose that construct c
  921.      contains a dynamic-extent declaration for variable (or function) v (which
  922.      need not be bound by c). Consider the values    taken on by v during the
  923.      course of some execution of c. The declaration asserts that if some object
  924.      x is an otherwise inaccessible part of    whenever    becomes the value of
  925.      v, then just after execution of c terminates x will be either inaccessible
  926.      or still an otherwise inaccessible part of the value of v. If this
  927.      assertion is ever violated, the consequences are undefined.
  928.  
  929.      In some implementations, it is possible to allocate data structures in a
  930.      way that will make them easier to reclaim than by general-purpose garbage
  931.      collection (for example, on the stack or in some temporary area). The
  932.      dynamic-extent declaration is designed to give the implementation the
  933.      information necessary to exploit such techniques.
  934.  
  935.      For example, in the code fragment
  936.  
  937.      (let ((x (list 'a1 'b1 'c1))
  938.            (y (cons 'a2 (cons 'b2 (cons 'c2 'd2)))))
  939.        (declare (dynamic-extent x y))
  940.        ...)
  941.  
  942.      it is not difficult to prove that the otherwise inaccessible parts of x
  943.      include the three conses constructed by list, and that the otherwise
  944.      inaccessible parts of y include three other conses manufactured by the
  945.      three calls to cons. Given the presence of the dynamic-extent declaration,
  946.      a compiler would be justified in stack-allocating these six conses and
  947.      reclaiming their storage on exit from the let form.
  948.  
  949.      Since stack allocation of the initial value entails knowing at the
  950.      object's creation time that the object can be stack-allocated, it is not
  951.      generally useful to declare dynamic-extent for variables that have no
  952.      lexically apparent initial value. For example,
  953.  
  954.      (defun f ()
  955.        (let ((x (list 1 2 3)))
  956.          (declare (dynamic-extent x))
  957.          ...))
  958.  
  959.      would permit a compiler to stack-allocate the list in x. However,
  960.  
  961.      (defun g (x) (declare (dynamic-extent x)) ...)
  962.      (defun f () (g (list 1 2 3)))
  963.  
  964.      could not typically permit a similar optimization in f because of the
  965.      possibility of later redefinition of g. Only an implementation careful
  966.      enough to recompile f if the definition of g were to change incompatibly
  967.      could stack-allocate the list argument to g in f.
  968.  
  969.      Other interesting cases are
  970.  
  971.      (declaim (inline g))
  972.      (defun g (x) (declare (dynamic-extent x)) ...)
  973.      (defun f () (g (list 1 2 3)))
  974.  
  975.      and
  976.  
  977.      (defun f ()
  978.        (flet ((g (x) (declare (dynamic-extent x)) ...))
  979.          (g (list 1 2 3))))
  980.  
  981.      In each case some compilers might realize the optimization is possible and
  982.      others might not.
  983.  
  984.      An interesting variant of this is the so-called stack-allocated rest list,
  985.      which can be achieved (in implementations supporting the optimization) by
  986.  
  987.      (defun f (&rest x)
  988.        (declare (dynamic-extent x))
  989.        ...)
  990.  
  991.      Note here that although the initial value of x is not explicitly present,
  992.      nevertheless in the usual implementation strategy the function f is
  993.      responsible for assembling the list for x from the passed arguments, so
  994.      the f function can be optimized by a compiler to construct a
  995.      stack-allocated list instead of a heap-allocated list.
  996.  
  997.      Some Common Lisp functions take other functions as arguments; frequently
  998.      the argument function is a so-called downward funarg, that is, a
  999.      functional argument that is passed only downward and whose extent may
  1000.      therefore be dynamic.
  1001.  
  1002.      (flet ((gd (x) (atan (sinh x))))
  1003.        (declare (dynamic-extent #'gd))     ;mapcar won't hang on to gd
  1004.        (mapcar #'gd my-list-of-numbers))
  1005.  
  1006.      The following three examples are in error, since in each case the value of
  1007.      x is used outside of its extent.
  1008.  
  1009.      (length (let ((x (list 1 2 3)))
  1010.                (declare (dynamic-extent x))
  1011.                x))                                    ;Wrong
  1012.  
  1013.      The preceding code is obviously incorrect, because the cons cells making
  1014.      up the list in x might be deallocated (thanks to the declaration) before
  1015.      length is called.
  1016.  
  1017.      (length (list (let ((x (list 1 2 3)))
  1018.                      (declare (dynamic-extent x))
  1019.                      x)))                             ;Wrong
  1020.  
  1021.      In this second case it is less obvious that the code is incorrect, because
  1022.      one might argue that the cons cells making up the list in x have no effect
  1023.      on the result to be computed by length. Nevertheless the code briefly
  1024.      violates the assertion implied by the declaration and is therefore
  1025.      incorrect. (It is not difficult to imagine a perfectly sensible
  1026.      implementation of a garbage collector that might become confused by a cons
  1027.      cell containing a dangling pointer to a list that was once stack-allocated
  1028.      but then deallocated.)
  1029.  
  1030.      (progn (let ((x (list 1 2 3)))
  1031.               (declare (dynamic-extent x))
  1032.               x)                                      ;Wrong
  1033.             (print "Six dollars is your change have a nice day NEXT!"))
  1034.  
  1035.      In this third case it is even less obvious that the code is incorrect,
  1036.      because the value of x returned from the let construct is discarded right
  1037.      away by the progn. Indeed it is, but ``right away'' isn't fast enough. The
  1038.      code briefly violates the assertion implied by the declaration and is
  1039.      therefore incorrect. (If the code is being interpreted, the interpreter
  1040.      might hang on to the value returned by the let for some time before it is
  1041.      eventually discarded.)
  1042.  
  1043.      Here is one last example, one that has little practical import but is
  1044.      theoretically quite instructive.
  1045.  
  1046.      (dotimes (j 10)
  1047.        (declare (dynamic-extent j))
  1048.        (setq foo 3)                     ;Correct
  1049.        (setq foo j))                    ;Erroneous-but why? (see text)
  1050.  
  1051.      Since j is an integer by the definition of dotimes, but eq and eql are not
  1052.      necessarily equivalent for integers, what are the otherwise inaccessible
  1053.      parts of j, which this declaration requires the body of the dotimes not to
  1054.      ``save''? If the value of j is 3, and the body does (setq foo 3), is that
  1055.      an error? The answer is no, but the interesting thing is that it depends
  1056.      on the implementation-dependent behavior of eq on numbers. In an
  1057.      implementation where eq and eql are equivalent for 3, then 3 is not an
  1058.      otherwise inaccessible part because (eq j (+ 2 1)) is true, and therefore
  1059.      there is another way to access the object besides going through j. On the
  1060.      other hand, in an implementation where eq and eql are not equivalent for
  1061.      3, then the particular 3 that is the value of j is an otherwise
  1062.      inaccessible part, but any other 3 is not. Thus (setq foo 3) is valid but
  1063.      (setq foo j) is erroneous. Since (setq foo j) is erroneous in some
  1064.      implementations, it is erroneous in all portable programs, but some other
  1065.      implementations may not be able to detect the error. (If this conclusion
  1066.      seems strange, it may help to replace 3 everywhere in the preceding
  1067.      argument with some obvious bignum such as 375374638837424898243 and to
  1068.      replace 10 with some even larger bignum.)
  1069.  
  1070.      The dynamic-extent declaration should be used with great care. It makes
  1071.      possible great performance improvements in some situations, but if the
  1072.      user misdeclares something and consequently the implementation returns a
  1073.      pointer into the stack (or stores it in the heap), an undefined situation
  1074.      may result and the integrity of the Lisp storage mechanism may be
  1075.      compromised. Debugging these situations may be tricky. Users who have
  1076.      asked for this feature have indicated a willingness to deal with such
  1077.      problems; nevertheless, I do not encourage casual users to use this
  1078.      declaration.
  1079.  
  1080. [change_end]
  1081.  
  1082. An implementation is free to support other (implementation-dependent)
  1083. declaration specifiers as well. On the other hand, a Common Lisp compiler is
  1084. free to ignore entire classes of declaration specifiers (for example,
  1085. implementation-dependent declaration specifiers not supported by that
  1086. compiler's implementation), except for the declaration declaration specifier.
  1087. Compiler implementors are encouraged, however, to program the compiler to issue
  1088. by default a warning if the compiler finds a declaration specifier of a kind it
  1089. never uses. Such a warning is required in any case if a declaration specifier
  1090. is not one of those defined above and has not been declared in a declaration
  1091. declaration.
  1092.  
  1093. -------------------------------------------------------------------------------
  1094.  
  1095. 9.3. Type Declaration for Forms
  1096.  
  1097. Frequently it is useful to declare that the value produced by the evaluation of
  1098. some form will be of a particular type. Using declare one can declare the type
  1099. of the value held by a bound variable, but there is no easy way to declare the
  1100. type of the value of an unnamed form. For this purpose the the special form is
  1101. defined; (the type form) means that the value of form is declared to be of type
  1102. type.
  1103.  
  1104. [Special Form]
  1105. the value-type form
  1106.  
  1107. The form is evaluated; whatever it produces is returned by the the form. In
  1108. addition, it is an error if what is produced by the form does not conform to
  1109. the data type specified by value-type (which is not evaluated). (A given
  1110. implementation may or may not actually check for this error. Implementations
  1111. are encouraged to make an explicit error check when running interpretively.) In
  1112. effect, this declares that the user undertakes to guarantee that the values of
  1113. the form will always be of the specified type. For example:
  1114.  
  1115. (the string (copy-seq x))     ;The result will be a string
  1116. (the integer (+ x 3))         ;The result of + will be an integer
  1117. (+ (the integer x) 3)         ;The value of x will be an integer
  1118. (the (complex rational) (* z 3))
  1119. (the (unsigned-byte 8) (logand x mask))
  1120.  
  1121. The values type specifier may be used to indicate the types of multiple values:
  1122.  
  1123. (the (values integer integer) (floor x y))
  1124. (the (values string t)
  1125.      (gethash the-key the-string-table))
  1126.  
  1127. [change_begin]
  1128. X3J13 voted in June 1989 (THE-AMBIGUITY)   to clarify that value-type may be
  1129. any valid type specifier whatsoever. The point is that a type specifier need
  1130. not be one suitable for discrimination but only for declaration.
  1131.  
  1132. In the case that the form produces exactly one value and value-type is not a
  1133. values type specifier, one may describe a the form as being entirely equivalent
  1134. to
  1135.  
  1136. (let ((#1=#:temp form)) (declare (type value-type #1#)) #1#)
  1137.  
  1138. A more elaborate expression could be written to describe the case where
  1139. value-type is a values type specifier.
  1140. [change_end]
  1141.  
  1142. -------------------------------------------------------------------------------
  1143. Compatibility note: This construct is borrowed from the Interlisp DECL package;
  1144. Interlisp, however, allows an implicit progn after the type specifier rather
  1145. than just a single form. The MacLisp fixnum-identity and flonum-identity
  1146. constructs can be expressed as (the fixnum x) and (the single-float x).
  1147. -------------------------------------------------------------------------------
  1148.  
  1149.  
  1150.  
  1151.  
  1152.